Les cartes de récits utilisateurs sont un outil précieux pour développer et superviser de manière créative la multitude d'idées et de fonctionnalités d'un produit. Elles permettent de s'affranchir des limitations unidimensionnelles d'un backlog et de discuter et prioriser les récits tout au long du processus de développement. Cerise sur le gâteau : les objectifs des différents rôles utilisateurs restent toujours au cœur des préoccupations.
Jeff Patton est considéré comme le pionnier et l'inventeur du story map. Il a également écrit un excellent ouvrage sur le sujet (Patton, Jeff ; User Story Mapping ; O'Reilly Media). Loin d'être un guide technique sur la création d'un story map et le choix des notations, ce livre démontre comment une équipe (et ses parties prenantes) peut utiliser le story map pour concevoir, discuter et prioriser un produit selon une approche centrée sur l'utilisateur, à différents niveaux de détail.
Les trois niveaux
En pratique, il s'avère utile de considérer trois niveaux différents. Toutefois, il ne s'agit en aucun cas d'une norme ISO ou d'une norme similaire. Si, dans un contexte donné, il est pertinent de subdiviser un ou plusieurs niveaux, n'hésitez pas.
Le d'activité de l'utilisateur décrit les actions qu'il souhaite effectuer avec le produit. Par exemple : « envoyer un e-mail », « publier une photo » ou « générer une déclaration d'intérêt ». Pour s'en souvenir, on peut imaginer que l'utilisateur peut faire une pause-café après avoir terminé une activité. Chaque activité est associée à un rôle utilisateur. Il est important de noter qu'un système tiers peut également endosser ce rôle (à l'instar des acteurs d'un diagramme de cas d'utilisation). Ces acteurs, bien sûr, ne peuvent pas faire de pause-café ! :) Un atelier d'équipe dédié est recommandé afin d'identifier un maximum de personnes et de systèmes impliqués dans le produit, facilitant ainsi la définition de ces rôles.
Le deuxième niveau – les tâches de l’utilisateur – décrit le processus. Patton parle de la « colonne vertébrale » ou du « flux ». Il s’agit des étapes individuelles à suivre pour réaliser l’activité. Exemples :
- Envoyer un e-mail : Ouvrez un e-mail vierge, saisissez le destinataire, rédigez le texte, ajoutez une pièce jointe
- Publier une photo : Sélectionnez une photo, appliquez des filtres, décorez-la de façon créative, puis soumettez-la
- Création d'un relevé d'intérêts : Préparation des données du compte, calcul des intérêts, envoi des données au système de sortie, enregistrement du PDF dans l'archive
Les tâches doivent être classées selon leur habituel . Il existe souvent plusieurs possibilités. Discuter de cet ordre est une ressource précieuse pour identifier les tâches non encore réalisées et mieux comprendre le produit.
Le troisième niveau consigne les détails d'une tâche. De nombreuses tâches peuvent être accomplies de différentes manières. Ces alternatives constituent les scénarios utilisateurs potentiels. Exemple :
- Saisir le destinataire : Saisissez le destinataire, sélectionnez-le dans le carnet d’adresses, utilisez la saisie semi-automatique, mettez le destinataire en copie…
- Sélectionner une photo : choisir une photo dans le dossier de l’appareil photo, importer une photo, choisir une photo dans OneDrive
- Calcul des intérêts : Déterminez le taux d’intérêt, tenez compte des taux d’intérêt préférentiels, déduisez la retenue à la source….
collaboration
La cartographie des récits utilisateurs repose sur la collaboration. Elle est élaborée, enrichie, discutée et priorisée conjointement par l'équipe et les parties prenantes . Une carte physique affichée au bureau est facilement personnalisable. Par exemple, des autocollants de couleur peuvent représenter les récits avec leurs dépendances, le logo de l'équipe responsable ou des symboles indiquant la complexité.
Quiconque a déjà travaillé avec des cartes de récits utilisateurs physiques connaît également leurs faiblesses :
- La taille de la carte augmente très rapidement et les murs sont limités.
- Déplacer des post-it est très fastidieux, surtout au début, quand toutes les activités ou tâches n'ont pas encore été identifiées. Et que faire de tous ces post-it qui traînent par terre dès le matin ?
- Finalement, les articles sont intégrés au système numérique de suivi des problèmes et ce backlog unidimensionnel devient la base de la discussion – la vision d'ensemble est à nouveau perdue.
- Les équipes distribuées ne bénéficient pas de cette précieuse technologie.
Pour pallier ces faiblesses, nous avons, avec nos collègues de Swarmit , recherché des outils pour les cartes narratives numériques et les avons décrits en détail dans cet article :
Carte des récits utilisateurs – Les outils
Par où commencer ?
Pour découvrir les User Story Maps, l'exercice matinal décrit par Patton dans son livre est idéal. Vous pouvez en savoir plus ici ou le mettre en pratique directement dans notre cours « Comment créer des User Story ».
Pour obtenir une vue d'ensemble, les guides de référence rapide et les présentations de Patton – en complément du livre – sont fortement recommandés.
Pouvons-nous vous aider à réaliser l'exercice de planification des routines matinales ou à créer une cartographie des récits utilisateurs pour un produit nouveau ou existant ? Nous serions ravis de vous aider à découvrir et à utiliser la cartographie des récits utilisateurs. Contactez-nous pour une consultation gratuite ou pour en savoir plus sur nos formations.
Comment créer une histoire utilisateur
Allons-y!
Le principal avantage de la carte narrative réside dans sa double dimension. Tandis que le flux décrit les tâches à accomplir, les trois niveaux permettent d'en explorer les détails plus en profondeur. Grâce à ces concepts, la perspective globale est toujours conservée lors des discussions, et il est possible de passer d'un niveau à l'autre avec aisance. La carte narrative s'adapte ainsi à presque tous les types de logiciels – même s'il faut parfois faire preuve d'un peu d'imagination concernant les rôles, les activités et les tâches des utilisateurs (conseil : choisissez des rôles d'utilisateurs interagissant le plus directement possible avec votre produit. Si votre système fournit des données au système X et que l'utilisateur « réel » travaille avec le système X, le rôle « Système X » est probablement plus approprié).
Exemple : Carte narrative pour le cours « Comment créer une user story »
On pourrait croire que les story maps ne conviennent qu'aux nouveaux développements. Pourtant, elles offrent un cadre idéal pour (re)constituer ou documenter une vue d'ensemble complète des systèmes existants. En analysant les tâches accomplies par le système et les fonctions qui les sous-tendent, on retrouve non seulement le contexte (s'il a été perdu ou n'est connu que de quelques-uns), mais on dispose également d'un outil pour identifier de nouvelles fonctionnalités pertinentes.
Essayez-le ! Si vous le souhaitez, n'hésitez pas à partager votre expérience avec Story Maps dans les commentaires.
Bonne chance!
Cordialement, Benjamin Wyss
